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Controlling quality of service in a mobile communications system 

Background off the invention 

The invention relates to controlling Quality of Service (QoS) in mo- 
bile communications systems having a packet data transmission capab.lrty. 

Mobile communications system refers generally to any telecommu- 
nications system which enables a wireless communication when users are 
moving within the service area of the system. A typical mobile communications 
system is a Public Land Mobile Network (PLMN). 

The mobile communications network is usually an access network 
providing a user with a wireless access to external networks, hosts, or serv.ces 
offered by specific service providers. 

The general packet radio service GPRS is a new service in the 
GSM system (Global system for mobile communications), and is one ofthe 
objects of the standardization work of the GSM phase 2+ at the ETS 
(European Telecommunications Standards Institute). The GPRS operat,onal 
environment comprises one or more subnetwork service areas, wh.ch are in- 
terconnected by a GPRS backbone network. A subnetwork comprises a num- 
ber of packet data service nodes, referred to as serving GPRS support nodes 
SGSN each of which is connected to the GSM mobile communication network 
(typically to base station systems BSS) in such a way that it can provide a 
packet service for mobile data terminals via several base stations, i.e. cells. 
The intermediate mobile communication network provides packet-switched 
data transmission between a support node and mobile data terminals. Differ- 
ent subnetworks are in turn connected to an external data network, e.g. to a 
25 public switched data network PSPDN, via GPRS gateway support nodes 
GGSN. The term GSN refers commonly to both SGSN and GGSN. The GPRS 
service thus allows to provide packet data transmission between mobile data 
terminals and external data networks when the GSM network functions as an 
access network. 

30 In order to access the GPRS services, a mobile station (MS) shall 

first make its presence known to the network by performing a GPRS attach. 
This operation establishes a logical link between the MS and the SGSN, and 
makes the MS available for Short Message Service (SMS) over GPRS, paging 
via the SGSN, and notification of incoming GPRS data. More particularly, 

35 when the MS attaches to the GPRS network, i.e. in a GPRS attach procedure, 



20 
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the SGSN creates a mobility management context (MM context). The authen- 
ication of the user «s also carried out by the SGSN in the GPRS attach proce- 
T^n oZr to send and receive GPRS data, the MS shall activate the 
pacte data address that it wants to use, by requestfng .POP (Packet Data 
5 Protocol) activation procedure. This operation makes the MS known ,n the cor- 
responding GGSN, and intending with external date ne^orks can com- 
mence. More particularly, a POP context is created « the MS and the GGSN 
and the SGSN. The PDP context defines different data transm,ss,on parame- 
ters, such as the PDP type (e.g. X.25 or IP). PDP address (e.g. an X.121 ad- 
,o dress), qualrty of service QoS and NSAPI (Network Serv,ce Access Point 
"dentifier). The MS activates the PDP context wKh a ^TT^t 
vate PDP Context Request, in which it gives information on the Temporary 
Logical Link Identity (TLLI). PDP type, PDP address, requ.red QoS and 
NSAPI. and optionally the access point name APN. 

Figure 1 illustrates a GPRS packet radio network implemented .n 
the GSM system. For a more detailed description of the GPRS, a reference ,s 
made to ETSI GSM 03.60. version 6.1 .0, and the cross-references thereof. 

The basic structure of the GSM system comprises two subsystems: 
a base station system BSS and a network subsystem NSS. The BSS and mo- 
20 bile stations MS communicate with each other over radio links. In the base 
station system BSS. each cell is served by a base station BTS. A number of 
base stations are connected to a base station controller BSC which con rols 
the radio frequencies and channels used by the BTS. Base station controllers 
BSC are connected to a mobile services switching centre MSC. As regards a 
25 more detailed description of the GSM system, reference is made to the 
ETSI/GSM recommendations and The GSM System for Mobile Communica- 
tions, M. Mouly and M. Pautet, Palaiseau, France. 1992, ISBN:2-9571 90-07-7. 

In figure 1. the GPRS system connected to the GSM network com- 
prises one GPRS network, which in turn comprises one serving GPRS support 
so node (SGSN) and several GPRS gateway support nodes (GGSN). The differ- 
ent support nodes SGSN and GGSN are interconnected by an mtra-operator 
backbone network. In the GPRS network there may be any number of sen/.ng 
support nodes and gateway support nodes. 

The serving GPRS support node SGSN is a node which serves the 
35 mobile station MS. Each SGSN controls packet data service within the area of 
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one or more cells in a cellular packet radio network and thereto^ each 
SGSN is connected (via a Gb interface) to a certain local element of the GSM 
system. This connection is typically established to the base statin system 
BSS Te- to base station controllers BSC or to a base station BTS. The mobite 
station MS located In a cel. communicates through the ^^^^ 
network with a BTS over a radio interface and further with the SGSN to the 
service area of which the cell belongs. In principle, the mobiie communion 
network between the SGSN and the MS only relays packets between these 
two. To achieve this, the mobile communication network P«^P"** 
switched transmission of data packets between the MS and the , SGSN. Jt has 
to be noted that the mobile communication network only provides a physical 
connection between the MS and the SGSN, and thus its exact function and 
structure is not significant with respect to the invention. The SGSN ^ *o p£ 
vided with a signing interface Gs to the visitor location register VLR of the 
mobile communication network and/or to the mobile services swrtch.ng centre, 
e a signalling connection SS7. The SGSN may transmit location .nformat.on 
to the MSC/VLR and/or receive requests for searching for a GPRS subscriber 

from the MSC/VLR. . . 

The GPRS gateway support nodes GGSN connect an operator's 
GPRS network to external systems, such as other operators' GPRS systems 
data networks 11. such as an IP network (Internet) or a X.2S network, and 
service centers. A border gateway BG provides an access to an inter-operator 
GPRS backbone network 12. The GGSN may also be connected directly to a 
private corporate network or a host. The GGSN includes GPRS subscribers 
POP addresses and routing information, i.e. SGSN addresses. Routing infor- 
mation is used for tunnelling protocol data units PDU from data network 11 to 
the current switching point of the MS. i.e. to the serving SGSN. The function- 
alities of the SGSN and GGSN can be connected to the same physical node. 

The home location register HLR of the GSM network contains 
, GPRS subscriber data and routing information and it maps the subscriber's 
IMSI into one or more pairs of the PDP type and PDP address. The HLR also 
maps each PDP type and PDP address pair into one or more GGSNs. The 
SGSN has a Gr interface to the HLR (a direct signalling connection or via an 
internal backbone network 13). The HLR of a roaming MS and its serv.ng 
5 SGSN may be in different mobile communication networks. 
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An intra-operator backbone network 13. which interconnects an op- 
erator's SGSN and GGSN equipment can be implemented, for example, by 
means of a local network, such as an IP network. It should be noted that an 
operator's GPRS network can also be implemented without the intra-operator 
backbone network, e.g. by providing all features in one computer. 

An inter-operator backbone network enables a commun.cat.on be- 
tween different operators' GPRS networks. 

in order to send and receive GPRS data, the MS shall actrvate the 
packet data address that it wants to use, by requesting a POP activation pro- 
cedure This operation makes the MS known in the corresponding GGSN, and 
interworking with external data networks can commence. More part.cularly. a 
PDP context is created in the MS and the GGSN and the SGSN. 

As a consequence, three different MM states of the MS are typical 
of the mobility management (MM) of a GPRS subscriber: idle state, standby 
state and ready state. Each state represents a specific functionality and .nfor- 
mation level, which has been allocated to the MS and SGSN. Information sets 
related to these states, called MM contexts, are stored in the SGSN and the 
MS. The context of the SGSN contains subscriber data, such as the sub- 
scriber's IMSI, TLL1 and location and routing information, etc. 

In the idle state the MS cannot be reached from the GPRS network, 
and no dynamic information on the current state or location of the MS. i.e. the 
MM context, is maintained in the network. In the standby and ready states the 
MS is attached to the GPRS network. In the GPRS network, a dynamic MM 
context has been created for the MS. and a logical link LLC (Logical L.nk Con- 
trol) is established between the MS and the SGSN in a protocol layer. The 
ready state is the actual data transmission state, in which the MS can transmit 

and receive user data. 

In the standby and ready states, the MS may also have one or more 
PDP contexts (Packet Data Protocol), which are stored in the serving SGSN In 
connection with the MM context. The PDP context defines different data 
transmission parameters, such as the PDP type (e.g. X.25 or IP). PDP ad- 
dress (eg an X.121 address), QoS and NSAPI. The MS activates the PDU 
context with a specific message, Activate PDP Context Request, in which it 
gives information on the TLLl, PDP type. PDP address, required QoS and 
i NSAPI. and optionally the access point name APN. When the MS roams to the 
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area of a new SGSN, the new SGSN requests MM and PDP contexts from the 
old SGSN. 

As shown if Fig. 2, a GPRS system comprises layered protocol 
structures cailed planes for signalling and transmitting user information. The 
5 signalling plane consists of protocols for control and support of 

sion plane functions. The transmission plane cons.sts of a layered protocol 
structure providing user information transfer, along with associated .nformation 
transfer control procedures (e.g.. flow control, error detection, error correction 
and error recovery). The Gb interface keeps the transmission plane of the 
10 NSS platform independent of the underlying radio interface. 

GPRS Tunnelling Protocol (GTP) tunnels user data and stalling 
between GPRS support nodes in the GPRS backbone network. All PDP-PDUs 
shall be encapsulated by the GTP. GTP provides mechanisms for flow control 
between GSNs, if required. GTP is specified in GSM 09.60. Transmission 
15 Control Protocol (TCP) carries GTP-PDUs in the GPRS backbone network for 
protocols that need a reliable data link (e.g., X.25). and UDP cames GTP- 
PDUs for protocols that do not need a reliable data link (e.g. IP). TCP provides 
flow control and protection against lost and corrupted GTP ; P ° U D S n ^ se ;^; 
gram protocol (UDP) provides protection against corrupted GTp - p °^ D TCP '^ 
20 defined in RFC 793. UDP is defined in RFC 768. Internet Protocol (IP) is the 
GPRS backbone network protocol used for routing user data and control sig- 
nalling The GPRS backbone network may initially be based on the IP version 
4 (IPv4) protocol. Ultimately, IP version 6 (IPv6) will be used. IP version 4 .s 

defined in RFC791. . a 

2 5 Subnetwork Dependent Convergence Protocol (SNDCP) is a 

transmission functionality which maps network-level characteristics onto the 
characteristics of the underlying network. SNDCP is specified in GSM 04.65. 
Logical Link Control (LLC) provides a highly reliable ciphered logical link. LLC 
shall be independent of the underlying radio interface protocols in order to al- 
so low introduction of alternative GPRS radio solutions with minimum changes to 
the NSS LLC is specified in GSM 04.64. Relay function relays LLC-PDUs. 
between the Urn and Gb interfaces in the BSS. In the SGSN, the Relay func- 
tion relays PDP-PDUs between the Gb and Gn interfaces. Base Station Sys- 
tem GPRS Protocol (BSSGP) conveys routing and QoS-related information 
35 between BSS and SGSN. BSSGP is specified in GSM 08.18. Frame Relay 
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,ayer transports BSSGP PDUs. RLC/MAC layer contains two tunc tons: The 
Radio Link Control function provides a radio-solution-dependent rel.able link 
The Medium Access Control function controls the access signalling (request 
and grant) procedures for the radio channel, and the mapping of LLC frames 
onto the GSM physical channel. RLC/MAC is described in GSM 03.64. 

Fig. 1 also shows the structure of a data packet DP. It compnses a 
payload PL carrying actual user information, and a number of headers H for 
identification, routing and priority information, etc. Each protocol layer adds a 
header of its own to the data packet. The item PrT will be explained later. 

Various identities are employed in the GPRS. A unique international 
Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber 
in GSM. This is also the case for GPRS-only mobile subscribers. A GPRS 
subscriber, identified by an IMSI. shall have one or more temporary and/or 
permanently associated network layer addresses, i.e. PDP addresses which 
conform to the standard addressing scheme of the respective network layer 
service used. A PDP address may be an IP address or an X.121 address. 
PDP addresses are activated and deactivated through SM (session manage- 
ment) procedures. 

The NSAPI and TLLI are used for network layer routing. A 
NSAPI/TLLI pair is unambiguous within a given routing area. In the MS, the 
NSAPI identifies the PDP service access point (PDP-SAP). In the SGSN and 
the GGSN the NSAPI identifies the PDP context associated with a PDP ad- 
dress Between the MS and the SGSN, the TLLI unambiguously identifies the 
logical link. NSAPI is a part of the tunnel identifier (TID). TID is used by the 

, GPRS tunnelling protocol between GSNs to identify a PDP context. A TID 
consists of an IMSI and an NSAPI. The combination of IMSI and NSAPI 
uniquely identifies a single PDP context. The TID is forwarded to the GGSN 
upon PDP Context activation and it is used in subsequent tunnelling of user 
data between the GGSN and the SGSN to identify the MS's PDP contexts in 

> the SGSN and GGSN. The TID is also used to forward N-PDUs (network-level 
Packet Data Units) from the old SGSN to the new SGSN at and after an inter 

SGSN routing update. 

Each SGSN and GGSN have an IP address, either of type IPv4 or 
IPv6, for inter-communication over the GPRS backbone network. For the 
5 GGSN. this IP address corresponds also to a logical GSN name. 
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GPRS transparently transports PDP-PDUs between external net- 
works and MSs. Between the SGSN and the GGSN. PDP-PDUs are routed 
and transferred with the IP protocol. The GPRS Tunnelling Protocol GTP 
transfers data through tunnels. A tunnel is identified by a tunnel identifier (TID) 
and a GSN address. All PDP-PDUs are encapsulated and decapsulated for 
GPRS routing purposes. Encapsulation functionality exists at the MS, at the 
SGSN and at the GGSN. Encapsulation allows PDP-PDUs to be delivered to 
and associated with the correct PDP context in the MS, the SGSN, or the 
GGSN Two different encapsulation schemes are used; one for the GPRS 
backbone networic between two GSNs. and one for the GPRS connection 

between a SGSN and an MS. 

Between an SGSN and a GGSN, the GPRS backbone network en- 
capsulates a PDP-PDU with a GPRS Tunnelling Protocol header, and it inserts 
this GTP-PDU in a TCP-PDU or UDP-PDU that again is inserted in an IP-PDU. 
The IP and GTP-PDU headers contain the GSN addresses and tunnel end- 
point identifier necessary to uniquely address a GSN PDP context. 

Between an SGSN and an MS, a PDP context is uniquely ad- 
dressed with a TLLl/NSAPI pair. The TLLI is assigned when the MS initiates 
the Attach function. NSAPIs are assigned when the MS initiates the PDP 
20 Context Activation function. 

Quality of service (QoS) defines how the packet data units (PDUs) 
are handled during transmission through the GPRS network. For example, the 
QoS defined for the PDP addresses control the order of transmission, buffer- 
ing (the PDU queues) and discarding of the PDUs in the SGSN and the 
GGSN, especially in a congested situation. Therefore, different QoS levels will 
present different end-to-end delays, bit rates and numbers of lost PDUs, for 

example, for the end users. 

A QoS profile is associated with each PDP Address. For example, 
some PDP addresses may be associated with e-mail that can tolerate lengthy 
response times. Other applications cannot tolerate delay and demand a very 
high level of throughput, interactive applications being one example. These 
different requirements are reflected in the QoS. If a QoS requirement is be- 
yond the capabilities of a PLMN, the PLMN negotiates the QoS as close as 
possible to the requested QoS. The MS either accepts the negotiated QoS or 
35 deactivates the PDP context. 
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Currently, a GPRS QoS profile contains five parameters: service 
precedence, delay 'class, reliability, and mean and peak bit rates. Service 
precedence defines some kind of priority for the packets belonging to a certain 
PDP context (i.e. which packets will be dropped in case of congestion). Delay 
class defines mean and maximum delays for the transfer of each data packet 
belonging to that context. Reliability in turn specifies whether acknowledged or 
unacknowledged services will be used at LLC (Logical Link Control) and RLC 
(Radio Link Control) layers. In addition, it specifies whether protected mode 
should be used in case of unacknowledged service, and whether the GPRS 
backbone should use TCP or UDP to transfer data packets belonging to the 
PDP context. Furthermore, these varying QoS parameters are mapped to four 
SAPIs (Service Access Point Identifiers) available at the LLC layer. 

The GPRS network is not capable of meeting the various QoS re- 
quirements of Internet applications. The IP (Internet Protocol) traffic takes 
place between a mobile host and a fixed host located in an external network, 
eg in the Internet. Different Internet applications require different kinds of 
service i e QoS, from the underlying network. Thus, when the mobile host is 
using GPRS to access the Internet, the GPRS network should be capable of 
meeting various QoS requirements of Internet applications. There are actually 
at least two IP traffic types that should be taken into account: real-time and 
non-real-time traffic One example of real-time traffic is voice transmission. E- 
mail and file transfer in turn are examples of non-real-time applications. 

Currently. QoS parameters can only be associated with a certain 
PDP context (i.e. a certain IP address, if the PDP type is IP). Therefore, set- 
ting different QoS values for different applications that use the same IP ad- 
dress is not possible. This is a very severe drawback of the current QoS 
scheme. The current GPRS specifications also define only very static QoS be- 
haviour A mobile station can only initiate a QoS negotiation when activating 
the PDP context. To summarise the main problems: The GPRS QoS scheme 
is too static, i.e. the QoS cannot be changed by the MS or the GGSN after the 
QoS has been negotiated for the first time, and moreover, all applications that 
use the same IP address must also use the same QoS profile, i.e. the QoS 
values. This is obviously not sufficient for supporting the requirements of vari- 
ous Internet applications and traffic streams, such as voice transmission, real- 



♦ • 10/ 8/Sa 17-OZ- +358 9 602244 -> PATREK ASIAKASPALVELU; Sivu 11 

fiUG-10-1998 17:02 FROtl^^STER OY ftB TO 693jg28 P. 11/39 



g 



time video, compressed video, e-mail transfer, file transfer, and high priority 
control information exchange. 

The Internet includes at the moment two different QoS schemes: 
Integrated Services and Differentiated Services. Integrated Services consist of 
5 three traffic types: Guaranteed Service, Controlled Load Service, and Best- 
Effort Service. Guaranteed Service is very difficult to provide without introduc- 
ing a large amount of overhead to the system. The reason for this overhead is 
that end-to-end traffic flows should be established for different application 
connections. Therefore, this requires large amounts of database management, 
10 control information exchange, and traffic policing to be performed by the sys- 
tem Controlled Load provides unloaded network behaviour even under con- 
gested situations. Controlled Load can be implemented by means of priorities. 
Therefore, implementing Controlled Load Service would probably be easier 
than Guaranteed Service, which needs strict guarantees on transmission de- 
15 lays etc. Best-Effort Service does not need any guarantees on the QoS, and is 
thus very easy to implement in any network. 

Differentiated Services in the Internet are based on the idea that no 
data flows are needed, but instead every data packet carries QoS information 
itself This allows a very flexible and easy way to provide a certain QoS to the 
20 applications. The drawback is that the capacity cannot be fully guaranteed be- 
cause no fixed capacity is ever allocated to a certain application flow. How- 
ever, this scheme is much more efficient from the capacity and system point of 
view than the Integrated Services scheme. 

Similar problems as described above may arise in any mobile 

25 communications network. 

Summary of the invention 

An object of the present invention is to introduce a new and im- 
proved Quality of Service (QoS) scheme which is more flexible than the prior 
art QoS schemes in mobile communications systems having a packet data 

30 transmission capability. 

Another object of the present invention is a new QoS scheme which 
provides support for Internet applications and their QoS requirements for mo- 
bile communications systems having a packet data transmission capability. 

The objects of the invention will be attained by the method and 
35 equipment which are characterized by what is disclosed in the attached inde- 
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pendent claims. Preferred embodiments of the invention are disclosed in the 

attached dependent claims. 

According to the invention, in connection with (i.e. during or after) 
PDP context activation, a mobile station MS may activate more than one QoS 
profile within the PDP context. In other words, an active PDP context for an 
MS comprises several QoS profiles. Transmitted packets are equipped with a 
profile tag or profile indicator indicating which profile the packet relates to. This 
profile tag is preferably 2, 3 or 4 bits in length, i.e. 4, 8 or 16 different profiles 

per context. . . 

When the MS begins to execute a new application requiring differ- 
ent service which cannot be provided by the existing profiles (i.e. one which 
has not been used during this session) a corresponding profile must be de- 
fined in the SGSN. For example, the MS could indicate that FTP requires pro- 
file 2 H323 requires profile 3, etc. Alternatively, this information can be config- 
ured manually or by some external signalling methods, e.g. QoS profile estab- 
lishment procedure or RSVP (Resource Reservation Protocol) signalling. 

According to a simple embodiment of the invention, the pnor art 
single profile for the PDP context is replaced with multiple profiles, one for 
each application, application type, or data flow, or aggregate for several flows. 
These multiple profiles are referred to as flow-related profiles, or simply flow 
profiles According to a preferred embodiment, there is provided a hybrid be- 
tween the prior art single profile and the simple embodiment's concept of 
separate flow profiles (one for each application, type or flow). This hybnd con- 
sists of one MS-related profile and several application-related flow profiles. 
The hybrid-profile concept is based on the idea that some QoS parameters 
characterise the MS's maximum capabilities (such as a maximum bit rate on 
the R reference point between an MT and a TE) or its user's maximum rights 
(such as a maximum allowed rate or the user importance: first class, business, 
etc ) Such maximum capabilities or rights are preferably defined in a common 
MS-related profile. If one of the flow profiles lack a parameter, then the corre- 
sponding parameter of the MS-related profile (i.e. the value common to all 
profiles) is used. Alternatively, there could be a default QoS profile for some or 
all PDP contexts and/or default values for the QoS profile(s). 
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Typical parameters for the flow profiles are reliability, peak bit rate, 
^an b* Z prudence - delay class <PN '^^^ 
characterises ofa^^ 

Instead of indicating a profile airecuy, * > 
ping ,o an externa, QoS (Resource Reservation Protocol. « S ™' «"'^ 
Zted services). For example, a mcb„e station ^ 

que s, could add a OcS ^^^g^^fiZL, wil, 

nackets will be encapsulated in GTP paweis inuiuauna H 

Tetld on - LLC layer ofthe appropnate SAP.. —^^.T 

.here Is a certain QoS associated or preconfigured with each SAPI value^ in 

oTr wokIsTqoS proflle should be mapped to the right SAP, 

tZXm Implies the, the peak throughput can be defined on a p^M. 

Ltead of on a proflie basis). Peak throughput could also be defined fo, ^both 

the MS in questton and each flow (or some of them). Then nether the 

per flow nor the MS's total traffic could exceed ^^ ondl "V^°^ 

peak throughput New QoS profiles can be established or triggered by RSVP 

stgnallg. palter negotiation, tag allocation procedures or predefined on 

an per-application basis. 

Internet applications are typically asymmetric, i.e. uplink and down- 
, link flows have different QoS requirements. For example, in vriec-on-demand 
' apXTons, vkteo games, etc. the uplink traffic Is typical* 

wNch requires reliable transmission but does not have any stnct delay re 
oulVments. Tne corresponding downlink traffic is downloaded vrieo mforma- 
ZZZ iust the opposite requirements: i, has an , upper M » on delay bu, 
5 missed frames can be ignored without undue harm. Two parameter sets have 
To be negated (either as separate QoS profHes for uplink and downlink, or a 
QoS profile includes two separate values for uplink and downhnk). 

The invention enables virtually any number of QoS profiles betng 
US ed simultaneously, e.g. a dedicated QoS profile for each o, j"*™ 
«, user applications being executed in the mobile station wrth the same IP ad 
n-b* profile tag can dlstingufeh between T. 
Therefore, the present invention provides support for venous Internet applica- 
Ls and their QoS requirements using only one IP address, which . > not pos- 
sible using the current QoS scheme of the GPRS. M ° re °^;^ le ' 
36 QoS profile has to be renegotiated, the same profile tag can st,ll be used. Th,s 



10/ B/98 17-03- -358 9 602244 -> PATREK AS I AKASPALVE LU ; Sivu 1« 

nU fiUG-10-1998 17:03 FROM KOLSTER OY PiB TO 69395328 P. 14/39 



12 



overcomes the problems relating to the static prior art QoS schemes. Further, 
the present invention introduces little overhead into the mobile communica- 
tions system as a whole. 

Implementing the invention involves some new issues. One of them 

5 is how the edges of the network can map the packets from the correct flow or 
profile. According to one possible solution, a process in the TE/MT/MS and 
GGSN (or some other node) manages the flow/profile associations and keeps 
track of which flows relate to which applications (or higher-level QoS 
schemes/aggregated flow, such as RSVP). This process can indicate these 

10 associations to the TE/MT/MS by providing each packet with a flow/profile tag 
which the MS uses to perform policing and scheduling and to forward the 
packet using the proper means (LLC acknowledged or unacknowledged). In 
this context, 'proper means' implies e.g. an appropriate LLC link using a par- 
ticular SAPI/QoS value (mapping to underlying layers based on the negotiated 

15 QoS profile values and using the reserved capacity for the profile flow). Alter- 
natively, the TE can use some other means and the MS can add the profile tag 
based on that information. The TE/MT/MS in turn forwards the profile tag in 

each packet it transmits. 

At the edges of the network (such as at the MS and the GGSN) a 
20 process may analyse every incoming packet and deduce to which flow/profile 
a given packet is associated and inserts the corresponding profile tag in the 
packet. This analysis and deduction can be based on an IP priority field <Jo$ 
or DS in IPv4; Traffic class or DS in IPv6), source and destination addresses, 
TCP/UDP port numbers, or an RSVP flow (a flow is identified by its IP address 
25 and port number). Both edges must maintain a table linking the profile tag to 
the corresponding applications (or higher-level QoS schemes). The edge 
which establishes a new profile association must signal the association to the 
other edge. The mechanism for this kind of signalling can be GPRS-specific 
mechanisms or some other suitable mechanism, such as RSVP carried across 
30 GPRS and mapped to GPRS-specific signalling means (i.e. a new QoS profile 
establishment procedure). 

The TE in the MT may use AT commands to signal the mapping 
information to the MS and the network, e.g. appropriate mapping between the 
profile tag and TCP/UDP port numbers. After this and the profile establishment 
35 operation, each packet could be mapped to the flow and the correct QoS pro- 
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file corresponding to the port number in both the GGSN and the MS. Also, 
some QoS profiles may be pre-established for carrying e.g. data packets re- 
lated to certain applications/port numbers. 

GTP uses flow labels which are defined in RFC-1883 as a mecha- 
nism to enable a source to label those packets for which it requests special 
handling by the IPv6 routers, such as non-default QoS or real-time service, n 
a network using GTP, the flow label could be used to carry the profile tags to 
indicate which flow and QoS profile a packet is associated. 

It is also conceivable that multiple flows are used for each PDP 
context and the packets carry not only a flow identifier but also other associ- 
ated QoS parameters. For example, in GPRS the precedence could be md,- 
cated per packet whereby it is not part of the QoS profile, or it overrides that 
value of the flow. However, the QoS profile of the flow might still include a de- 
fault value for the precedence. Such parameters could be set by the edge of 
the network in order to map the external QoS parameter (in this case, IP pnor- 
ity) or because more traffic than negotiated is transferred and additional 
packets might be marked. Such marking is analogous to using a discard b,t. 
Alternatively, a surtable tag could be inserted into SNDCP and GTP headers. 

The invention facilitates dynamic renegotiation. The QoS parame- 
ters associated with each flow can be renegotiated at any time without affect- 
ing other flows. Such renegotiation can be initiated by either edge of the net-, 
work or by an intermediate node. Additionally, should the need arise, the 
edges can also renegotiate a new mapping to external parameters or a port 

number. , 

Negotiating and renegotiating a QoS profile can involve all pa- 
rameters included the profile, a subset of the parameters, or a QoS class (e.g. 
a bit vector or an integer value). The possible QoS class value could md.cate, 
and also define, values for independent parameters. In other words, well- 
defined relations exist between the class and the independent parameters. 

) The classes could be defined in some ranking order A, B, etc. so that the ne- 
gotiation can be performed in one step as with LLC and SNDCP parameters. 
This requires that if a network element supports class A, it must also support 
all classes below it, i.e. B, C, etc. The QoS profile in the negotiation should be 
replaced by a QoS class field which is only 4 to. 8 bits (16 to 256 different 

5 classes). This could besimplified by requiring that peak and mean b.t rates are 
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alwa y S MS-specif,c (not flow-specific). If such a requirement .s cons.dered too 
restricting, an additional field or two fields could be used for brtmaps indicating 
hsH gLn class number in the (renegotiation has a peak/mean b, rate 
combined with an MS-specific value. Yet another alternative is to .separate the 
5 peak/mean bit rate from the classes and define them as an MS-specific pa- 
rameter which is negotiated separately from the classes. 

At both edges of the network, when a new external QoS reservation 
request (e g. an RSVP PATH message) arrives, a process decides whether a 
new flow should be established or an existing flow reused (modified, if neces- 
10 sary) in order to limit the number of simultaneous flows. One flow should be 
the default flow to which packets are associated if they do not include flow 

,dent.fiers. ^ ^ ^ perfoTTne d on the LLC or SNDPC layers, 

.t could be performed on a per-MS basis or on a per-class or per-context ba- 
15 sis Policing should be performed for N-PDUs because charging counts N- 
PDUs. Scheduling of packets can be performed on the BSSGP hP^cu»a 
it sees cell-specific pipes and retrieves traffic related to several MSs. The 
scheduling algorithm should take into account the delay and Precedence de- 
fined in the QoS profile in question (user priority). Admission control should 

20 consider the total load and calculate/decide what bit rates can be allocated to 
an individual MS. This can be summarised as follows: A process on the 
SNDPC layer polices the flow and forwards the packets which pass the pol.cer 
across the LLC layer to the scheduler on the BSSGP layer. The scheduler 
sends the packets to the BSS, or discards them in an overload situation.. In 

25 connection with a flow/profile establishment, admission control calculates, on 
the basis of the total load situation what bit rates can be guaranteed to a given 
flow. 

According to a preferred embodiment of the invention the profile in- 
dicated by the profile tag associated with each data packet includes at least a 

30 priority information and delay requirements. The delay class information has 
two or more values indicating the importance of the packet and thus also de-. 
fines the order in which data packets should be handled. In other words, rt de- 
fines a dropping preference to be used in case of network congestion. The pn- 
orrty information may also define a Nominal Bit Rate as in what is known as a 

35 SIMA approach (Simple Integrated Media Access, see example 1 below). At 
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least two traffic types having different delay requirements can be distin- 
guished: real-time and non-real-time traffic. For example, for non-rea.-t.me 
traffic types, the following subtypes could be distinguished: control traffic, in- 
teractive traffic, attended bulk transfer, unattended data transfer, filler traffic, 
5 uncharacterised traffic, and best-effort traffic. They can be indicated by using 
different delay class values for each type. The traffic type has an impact on 
retransmission strategies and data queuing in the network. For exampte. for 
real-time traffic, retransmission of lost data packets is usually not needed and 
it is often better to drop real-time data packets than to send them too late to 

10 the receiver. 

According to another embodiment of the invention, instead of, or in 

addition to employing reliability at a PDP context level, as is currently done in 
the prior art, reliability is also directly associated with the profile associated 
with the data packet. The communications network, e.g. at the LLC layer, «s ar- 
15 ranged to provide different connections, each of which is associated w.th dif- 
ferent reliability and QoS support. These connections may be provided in any 
one or several legs in the mobile communications network, e.g. at the radio 
interface and/or in a transmission link between two nodes in the network. One 
connection may be a connection oriented path having a higher reliability due to 
20 a retransmission protocol, for example, and another connection may be a con- 
nectionless path (e.g. using UDP) having a lower reliability. Data packets are 
multiplexed over these connections based on the reliability and QoS informa- 
tion associated with the profile in question (i.e. included in the QoS profile or 
indicated by the packet). The flows identified by the QoS profile tag requiring 
25 reliable transmission should be sent over a reliable connection-oriented path^ 
The packets in flows that do not require a reliable connection-oriented path 
should be sent over a connectionless path. Both the connection-oriented and 
the connectionless paths can be established to transfer packets of only one 
PDP context or they can be used by several PDPcontexts. Furthermore, the 
30 establishment of different paths with different reliability properties can be dy- 
namic or static (i.e. on demand or when the tunnel (PDP context) is created). 
This concept of the invention may applied in any packet data commun.cations 
network, even in one not using any PDP context, such as TCP/IP, ATM, or 
X.25 networks. 
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As noted above, the PDP context defines a kind of a transmission 
tunnel with specific characteristics through a mobile communications network. 
As in conventional networks, the parameters of the PDP context may .nclude a 
PDP type (e.g. X.25 or IP), a PDP address (e.g. IP address), and an NSAPI. 
5 The PDP context may also optionally include one or more QoS parameters. 

a ■*> hit rate for the whole PDP context can be 
For example, a mean and a peak bit rate tor tne wnoie ™r 

used The QoS of the PDP context may also include reliability. If both the 
PDP-level QoS profile and an additional QoS profile are to be used, the traffic 
policing may partly be based on the QoS values related to the PDP context 
n0 e g on the mean and peak bit rates. Therefore, if the user is sending at too 
high a speed, the priority of his or her data packets of certain flows could be 
temporary decreased by the system. This guarantees that packets not con- 
forming to the PDP level QoS contract are discarded first if needed. In addi- 
tion QoS information in the additional QoS profiles within the PDP context 
16 could be relevant only within the PDP context in question. This being the case, 
the QoS profile of a certain flow is taken into account only in relation with the 
global default QoS Profile of the PDP context. 

A further feature of the present invention may be a mapping of the 
QoS parameters used in the mobile-communication network to those used in a 
20 user application in said mobile packet data terminal or those used in an exter- 
nal communication system, and vice versa. The mapping is performed for 
each packet entering or leaving the mobile communications system. 

The profile tag in the data packets may be located in a packet 
header, in a lower layer protocol header, or as part of the data itself. The QoS 
25 controlling may also be based on the QoS information in the QoS profile which 
is related to a certain PDP context, the priority and traffic type information in- 
cluded in the data packets, or both. 

One embodiment of the invention involves also charging of the us- 
ers Users can be charged, in addition to the normal PDP level attributes, ao- 
30 cording to the attributes in independent QoS profiles. This requires that the 
mobile communications network nodes, such as the GSNs in the GPRS, col- 
lect information on the transferred data packets and the corresponding 
flows/profiles. On the other hand, the invention also allows charging schemes 
using the normal PDP-level attributes, such as the mean and peak bit rates of 
35 the PDP context, or a combination of these schemes. 
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According to a further preferred embodiment of the invention, the 
mobile communication, network is a packet radio network such the General 
Packet Radio Service (GPRS) of GSM or its evolution in the UMTS system. 
The present invention may also be implemented in a proprietary way: pay- 
loads of data packets could include a profile tag although the current GPRS 

QoS profile will still be used. 

This invention can also be applied to various future mob.le net- 
works, such as UMTS. 

Brief description of the several views of the drawing 

In the following, the invention will be described in greater detail by 
means of preferred embodiments with reference to the accompanying draw- 

ings, in which 

Fig 1 illustrates a GPRS network architecture; 
Fig. 2 illustrates a GPRS transmission plane and the use of the pro- 
15 file tags according to the invention; 

Fig. 3 illustrates a preferred arrangement of multiple profiles wrth.n a 

single PDP context; 

Fig. 4 illustrates the interworking between different network ele- 

metns; 

20 Fig. 5 shows a context activation procedure; and 

Fig. 6 shows a context modification procedure. 

Detailed description of the invention 

As shown in Fig. 1, the present invention can be applied to any mo- 
bile communications system having a packet data transmission capability. 

The term 'packet data protocol' (PDP) or 'PDP context as used 
herein should be understood to generally refer to any state in a mobile station 
and in at least one network element or functionality, which state provides a 
data packet transmission path or a tunnel with a specific set of parameters 
through the mobile communications network. The term 'node' as used herein 
should be understood to generally refer to any network element or functionary 
which handles the data packets transferred through the PDP channel. 

The invention can be especially preferably used for providing a 
general packet radio service GPRS in the pan-European digital mobile com- 



25 



30 
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munition system GSM or in corresponding mobile commun.cat.on systems, 
such as DCS1800 (also known as GSM1800) and PCS (Personal Communi- 
cation System). In the following, the preferred embodiments of the .nvention 
canon oy*iei. > ^p R <= racket radio network formed by the 

will be described by means of a GPRS packet raaio neiw , 
GPRS service and the GSM system without limiting the invention to this par- 
ticular packet radio system. 

A prior art data packet DP consists of a payload part PL and vanous 
headers H one for each protocol layer. According to the invention, the mobile 
station MS and the support nodes SGSN, GGSN, etc. maintain multiple pro- 
files Pr. each profile being tagged with a profile tag PrT. Each data packet DP 
also comprises a profile tag PrT indicating the relevant one of the multiple pro- 
files Pr Most protocols use headers where some bits are unused, redundant 
or reserved for further use. Such spare bits can be used for indicating the pro- 
file tag PrT, since typically only 2 to 4 bits are needed (4 to 16 different profiles 
per MS). If the headers do not have such redundant bits, the headers can be 
extended or the profile tag PrT can be appended to the payload part PL. 

Fig 3 illustrates the hybrid profile concept of the invention. For each 
PDP context, there is an MS-specfic and/or a PDP context-specific default 
profile Pr 0 which provides default values for some or ail of the QoS parame- 
ters For each application, application type or flow associated w.th the MS 
there may be a separate profile Pr. The separate profiles Pr are associated 
with the PDP context so that a profile tag with a small number of bits (e.g. 2 to 
4 bits) is sufficient to indicate the relevant profile Pr. Fig. 3 shows one such 
profile having an identifier of 2 and relating to an FTP application. For this ap- 
; plication, there are separate values for service precedence (y1). delay class 
(y2), reliability (y3) and mean bit rate (y4). However, no values are defined for 
the peak bit rate and hence the default value (x5) of the default profile Pr 0 will 

be used. . 

The QoS information associated with the profile indicated by the 

> PrT is employed in various nodes in the GPRS system for scheduling and po- 
licing the transmission of the data packets. As noted above, in the present 
GPRS specifications, QoS is associated with the PDP context, which causes- 
the various problems described above. According to the present invention, 
each data packet DP comprises a profile tag PrT whereby the scheduling and 

5 policing can be performed on a packet by packet basis (depending on the 
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flow). More particularly, the profile Pr associated with each data packet DP in- 
die*, at least one QoS parameter, and the scheduling and the policing of the 
transmission of the data packets is made on a packet by packet basis accord- 
ing to this QoS parameter indicated by the profile, while, however, within a 
-transmission tunnel" defined by the PDP context, if such a default ,s defined 
for the PDP context in question. 

According to a preferred embodiment of the invention, the QoS in- 
formation associated with the profile indicated by the profile tag includes at 
least priority information and a delay class information, and optionally, rel.ab.l- 
ity information. The delay class information has two or more values indicating 
the importance of the packet and thus it also defines the order in which data 
packets should be handled in case of network congestion. The pr.or.ty infor- 
mation may also define a Nominal Bit Rate as in the SIMA approach, or ,ndi- 
cate the discarding order of packets/flows. In addition to optionally having 
mean and peak bit rates in the profiles, this preferred embodiment of the in- 
vention requires typically the following modifications to GPRS specifications: 

1) As shown in Fig. 2. SNDCP and GTP headers should carry addi- 
tional bits for transmitting a profile tag (GTP bits are needed on both direc- 
tions SNDCP bits could in certain cases be used only for uplink data). In addi- 
tion *IPv4's Type-of-Service field or IPvS's priority field or Traffic Class field 
could be used in the GPRS backbone if it is wanted that IP routers etc. also 
support prioritisation of packets and QoS-based queuing or scheduling. RSVP 
could also be used within the GPRS backbone for providing specific flows with 
independent QoS handling. IPv6 traffic flows may be established for transmit- 
> ting data belonging to certain traffic types. It could also be possible that no ex- 
tra bits be allocated in the GTP headers, but the profile information is earned 
by lower layers. For example, if the underlying GPRS backbone network sup- 
portssuch mechanisms, this information can be included in an IP header or 
some other lower layer protocol header. This being the case, the SGSN and 
o the GGSN should be capable of recovering this lower layer information in or- 
der to reuse it The profile tag can be added to data packets at the Gb inter- 
face as well, e.g. to BSSGP protocol messages. Then the QoS information 
can be mapped to Frame Relay or ATM concepts at SGSN and BSS. 

2) In prior art system, a PDP context has a single QoS profile using 
is a single SAPl. Several PDP contexts could use the same SAPI if their QoS 
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profiles are similar. According to the invention, a single PDP context can use 
several SAPIs. The flows using the same SAPI should have similar QoS pro- 
files PDP contexts are multiplexed over several LLC SAPIs (e.g. if reliability .s 
used as one of the QoS parameters). In other words, the SNDC layer should 
5 be capable of multiplexing NSAPl on several SAPIs according to the QoS pro- 
file information at the LLC layer, as will be described in more detail below. 

No modifications are necessarily needed in the lower radio interface 
protocols, like RLC. However, radio interface protocols could be replaced later 
with newer protocols, such as Wideband CDMA (WCDMA). The present «n- 
10 vention is applicable also in such case and similar QoS support (priorrt.sat.on, 
traffic type/delays) to the one described herein could inherently be imple- 
mented into those radio protocols. 

Fig 4 illustrates the interworking between different network ele- 
metns After these modifications, a parameter-level mapping between differ- 
15 entiated services in the Internet and in GPRS may be provided as follows, for 

example: 

Priority information in the Internet is mapped to service precedence 

in GPRS. . * • 

An indication concerning real-time vs. non-real-time requirements in 

20 the Internet is mapped to delay class and/or reliability information in GPRS: at 
least two delay types are needed, but mapping of traffic types more precisely 
to several delay classes is also possible. 

Reliability information may be used to indicate the reliability re- 
quirements of each application in the form of one of at least two reliability 

25 classes. If reliable transmission (retransmissions, checksums and/or TCP) is 
needed the profile associated with the data packets indicates reliability class 
1 If reliable delivery over the radio interface is needed, but UDP in the GPRS 
backbone is sufficient, the profile associated with the data packets indicates 
reliability class 2. Depending on the requirements, the profile associated with 

30 the data packets may alternatively indicate reliability class 3, 4 or 5. Reliability 
classes 4 and 5 will be used for real-time traffic. 

A further feature of the present invention may be a mapping of the 
QoS parameters used in the mobile-communication network to those used in a 
user application in said mobile packet data terminal or those used in the exter- 
35 nal communication system, and vice versa. The mapping is made for each 
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packet entering or leaving the mobile communications system. In the following, 
two examples of the mapping will be given. 

Example 1. , ■ w 

Simple Integrated Media Access (SIMA) Is a new simple approach 
presented as an Internet-Draft by K. Kilkkl, Nokia Research Center, June 
1997. Internet-Drafts are working documents of the Internet Er^neenng Task 
Force (IETF), its areas, and working groups. SIMA is used as an example of 
3° "teL QOS scheme because it I. capable of providing a 
concept for different needs from file transfer applications using TCP/IP proto- 
loose delay and packet .oss requirements to readme appl^ons 
with very strict quality and availability requirements. According to the SIMA 
concept each user shall define only two Issues before the connect se up: a 
ntminal bit rate (NBR) and the selection between real-time and non-real-time 
^ classes. The NBR may have eight values 0 to 7. Mapping of parame- 
ters from SIMA to GPRS and vice versa may be as follows, for example: 
te Real-time/non-real-time bit: ■ mis bit indicates real-time require- 

ments it is mapped to GPRS delay class 1. otherwise it is mapped to delay 
Z?4. However, delay Cass 3 may be used for non-real-time services in 
case there is a special way to indicate best-effort traffic e.g. thus brt shall not 
always be present, or a more precise definition is used to differentiate real- 
time, non-real-time. and best-effort traffic. A lower Reliability Class «a lU e may 
be assigned to real-time traffic than to non-real-time traffic in GPRS. Gener- 
ally, Reliability classes 1 , 2, and 3 are usually used for non-real-time Uaffic and 
classes 3, 4, and 5 for real-time traffic in GPRS. For non-real-time traffic, the 
higher the NBR is, the lower Reliability Class value is suitable for transmission. 



NBR values 


GPRS service precedence value 


6 and 7 


1 


3. 4, and 5 


2 


0.1. and 2 


3 



It should be noted that the Service precedence and the Delay class 
parameters have here a somewhat different meaning from the current GPRS 
specifications, where those parameters are associated with PDP contexts, not 
30 with eachapplications. Thus, different names, such as priority or Nom.nal Brt 
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Ra ,e an, traffic type. « - - *-» JS^^'S 

Pr00edUre QoS scheduUng in GPRS netwo* elements (•* * . ^ 

GGSN) is based on the delay 1* J— S 

. , . . / _j 0 * mn e+ as rnanv as there are dinerem aeiay ^ lcao ° / 
"JST Z ZZSZZZZ* be much smaller.) and another one for 
Ttimfrckete ReaWme traffic should always be sent before non-real- 
i:Cc S "Lance defines the order in which pacKets can be 
dropped in case of network congestion. 

imping a Type of Service (ToS) octet in the headers of IP POUs to 
GPRS JSZ The & octet in an IP header Is not wider, used at ^ 

25 be used to indicate a ToS. . GpRS 

Mapping between the precedence brts (0 to 2 In ToS) and gpk* 

service precedence may be as follows: 



15 



hit values (0 to 2) 


service precedence value 


111 and 110 


001 fhiahest priority) 


101, 100- and 011 
mo 001. and 000 


010 (normal priority) 
m 1 /lowest priority) 
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There are three different ways to perform the mapping between the 
traffic type information (i.e. ToS field in the ToS octet) and the GPRS delay 

cldss* 

If only the bit 3 in the ToS field is used to indicate the delay re- 
5 quirements in IP header, value 0 of bit 2 is mapped to GPRS delay class 2 and 
value 1 of the bit 2 is mapped to GPRS delay class 4 (best effort). 

If the whole ToS field in ToS is used for indicating delay require- 
ments, i.e. 4 bits (bits 3-6) are available for that purpose, one possible map- 
ping could be: bit value 1000 is mapped to GPRS delay class 1 (i.e. to bit 
10 value 000). bit value 0100 to GPRS de.av class 2 (i.e. to value 001) ToS vaU 
ues 0010 and 0001 to GPRS delay class 3 (i.e. to value 010). and the ToS 

# value 0000 to GPRS delay class 4 (i.e. to value 011). 

Another way of mapping the IP's ToS bits to GPRS delay classes 
would be: 11X to delay class 1. 10x to delay class 2. 01x to delay class 3. and 
is OOx to delay class 4. In this case, x means that there might be one or more 
additional bits used for ToS. but they do not have any impact on the process of 
selecting the GPRS delay class. If more delay classes will be defined for 
GPRS later, the mapping could take into account also those additional bits. 

Currently there is also one bit in the IP ToS field specifying the de- 
20 sired reliability level. If this bit is still available in the future, e.g. if the first 
choice above is chosen, this bit could carry reliability information and could be 
.* . : mapped to GPRS reliability class in the following way: a value 0 in bit 5 inside 

V i the ToS octet is mapped to the reliability class 000 (subscribed reliability class) 

! : ' ' 5 and a value 1 is mapped to the reliability class 001 (defining the most reliable 

# 25 service) The use of that bit may however be too vague because the GPRS 
! ; defines many other reliability levels as well and this cannot be expressed us- 
ing only one bit. . 

The mapping described above in Example 2 may be applied in a 
rather similar way in IPv6. The name of the appropriate field is then Traffic 

<Y; 30 Class instead of ToS. 

Fig. 4 illustrates the operation of a GPRS mobile station and GPRS 
! ! : network elements, as well as integration with external network QoS concept^ 

: [ : * ; when the inventive multiple QoS concept and profile tag is employed. The MS. 

or more precisely, the software in the terminal equipment TE (e.g. in a laptop 
35 computer), and the GGSN provide mapping of external network QoS require- 
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:rrer^ 

of these operations, the ^rrto information, based 

pacKets with a profile ^^Zl t ST**- * e QoS 

on available information. The software 

file based on the used source and dest,nat.on IP addresses, 

Te* by the SGSN during POP context activafcn or mod**.. 

Fie 5 shows a context activation procedure. In step 5-1 the MS 
d s an Z2£*m Context Request (comprising an NSAP1. a POP type a 
1 Top add^I^ss Point Name, the requested QoS Profies and an as- 
L^P^Tag PrT an ^^^ZT^- 
and POP ^fZ^^^l^^ - inven.cn. in 

Tt 3" SOSN va^tes me request 5-1. The SGSN creates a Tunne. 
a step 5-3, the sgsn vaua » SGSN may res , ric t the re- 

ties and the current load. In step xne o« p rQ fi|es 
!e* Response (comprising a TID. a POP Address, the negotated ' 
35 !1 pr Jle tags PrT. and POP configuration options) to the SGSN. The SGSN 
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inserts the NSAPI with the GGSM address in the PDP context. Next in step 5- 
Hhe SGSN selects a Radio Priority Leve. based on each negotiated QoS 
o'rofile and returns an Activate PDP Context Accept (comprising a PDP type a 
PDP Address, an NSAP,, the negotiated QoS Profiles with associated profile 
6 Tags PrT, a Radio Priority Leve, and a SAP. for each QoS profile, nterwork.ng 
parameter and its associated PrT, and PDP configured options) to he MS. 
Now the SGSN is able to route PDP PDUs between the GGSN and the MS. 
The SAP1 indicates which QoS profile uses which SAPl. 

Fig 6 shows a context modification procedure. In step 6-1, the 
10 SGSN sends an Update PDP Context Request (comprising the TID, the nego- 
tiated QoS Profiles and an associated PrT. an Interworking parameter and its 
associated PrT) to the GGSN. This message is used to add. modrfy or cancel 
a QoS profile of a PDP context If the GGSN receives from the SGSN a nego- 
tiated QoS which is incompatible with the PDP context being modified (•* the 
15 reliability class in insufficient to support the PDP type), the GGSN ^ the 
request Compatible QoS profiles are configured by the GGSN operator The 
GGSN may again restrict the requested QoS attributes given its capab.ht.es. 
and the current load. The GGSN stores the negotiated QoS values and, _m 
step 6-2 returns an Update PDP Context Response (compns.ng the TID, the 
20 negotiated QoS Profiles and an associated PrT. an Interworking parameter 
and its associated PrT) to the SGSN. Next, in step 6-3, the SGSN sends a 
Modify PDP Context Request (comprising an NSAPI, the negotiated Q°SPro- 
files with associated profile tags PrT, a Radio Priority Level and a SAPl for 
each QoS profile. Interworking parameter and its associated PrT) to the MS. In 
25 step 6-4 the MS acknowledges by returning a Modify PDP Context Accept 
message If the MS does not accept the negotiated QoS Profiles, it can de- 
activate the corresponding PDP context(s) using a PDP Context Deactivation 
procedure. 

The choice whether to use retransmission or checksums at the 
30 LLC/RLC level depends on the reliability class of the corresponding profile. 
The reliability class defines either acknowledged or unacknowledged service 
of LLC, RLC and GTP. Scheduling in the lower layers is performed in accor- 
dance with the delay class of the corresponding profile. 
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The MS may also perform policing of the negotiated PDP context 
attributes of the QoS profile. It may drop non-conformant packets (or change 
the service precedence (i.e. the priority) of those packets to the worst possible, 
i e to indicate best-effort). In addition to the MS, an SGSN may also optionally 
perform traffic policing according to the negotiated QoS profile or PDP context 
level attributes. Network nodes may police the throughput levels and the used 
delay classes, reliability classes and service precedence values. Values nego- 
tiated for the PDP context may be interpreted as maximum allowed values or 
default values for the profiles. PDP context or profile-dependent QoS attributes 
form the basis for charging. For example, there could be a different counter 
associated with each profile used to charge the user. 

LLC establishes a connection over a SAPI when a new QoS profile 
is activated, requiring a new SAPI. This may happen at PDP context activation 
or modification (e.g. a creation of a new QoS profile). When all (QoS profile) 
flows using the SAPI are released, the LLC connection over this SAPI will also 
also released. Different QoS profiles can be employed between the MS and 
the SGSN. For example, the same SAPI could be used if the mean throughput 
is different but not if the delay class is different. Then it is required that the 
LLC/SNDCP layer multiplexes several NSAPls of one user onto several SAPIs 
20 in the MS and SGSN. The LLC/SNDCP layer in an SGSN decides, based on 
the QoS profile, which SAPI it will use to transfer the packets in a certain flow. 
The SNDC layer adds the corresponding profile tag to the data packets. It can 
perform segmentation of SN-PDUs as usual. Then the SNDC layer gives the 
packet to the LLC layer using the appropriate SAPI. The LLC layer transmits 
the packet over the LLC/radio connection as usual. At the other end, the 
SNDC layer receives packets from the different LLEs and associates them 
with the correct NSAPls and further to the corresponding profiles based on the 
profile tags. Maintaining the order of the packets using different QoS val- 
ues/profiles is not essential because packets using different QoS either belong 
to different application-level connections or are reordered according to their 
QoS values, which is the purpose of having the QoS values in the first place. 

The SGSN reads the QoS information, i.e. the service precedence, 
the delay class, the mean and peak bit rates, and the reliability class, of the 
profile associated with the uplink SNDCP packet, and schedules the packets 
based on this QoS profile. There may be different buffers for each allocated 



25 



30 
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delay class. The lower the delay class is. the smaller the size of a buffer allo- 
cated for queuing the concerned packet class should be. This is because 
some packets are delay sensitive, and thus cannot cope with long queuing 
delays Lower delay classes are normally sent before any higher delay class 
packets. Each buffer, i.e. a queue, may have a threshold value defined. When 
this threshold value is exceeded, the incoming packets (of the concerned 
class) having a low service precedence value may be discarded. An SGSN 
may maintain both reliable and unreliable paths to GGSNs. These paths might 
be dedicated to a certain user/profile, or. alternatively, several users and pro- 
, files might be multiplexed onto the same paths. The right path for del.ver.ng 
each data packet is selected based on the reliability class Information included 
in the profile, or based on default values if there is not enough information in 
the corresponding profile to make a decision. A reliable connection-oriented 
path is chosen for reliability class 1, and a connectionless path for other reli- 
5 ability classes. SGSN adds a profile tag to GTP headers. This information may 
be included in the 10th. 19th, or the 20th octet of the header (currently re- 
served for future use). 

The GGSN recovers the profile tag from the uplink GTP header. It 
may also perform traffic policing. The GGSN may perform charging functions 
o and it may utilise the QoS information relating to the profile for that purpose 
too The GGSN, or an external host, may provide a mapping between the ex- 
ternal data network QoS definitions and the GPRS QoS. and vice versa. This 
applies both for uplink and downlink data delivery. 

For Mobile Terminated (MT) data packets, the same procedure ap- 
>5 plies only the direction of transmission is reversed. In this case, the GGSN 
selects the appropriate QoS profile and GTP path. The SGSN looks inside the 
downlink GTP header in order to find the profile tag and it deduces the QoS 
information from its local profile record. The SGSN also adds the profile tag to 
downlink SNDCP packets, makes the scheduling based on delay class of the 
30 flow/profile, and uses the correct LLC SAPtassociated with the profile. The 
Mobile Terminal may change the application's IP header in order to inform the 
Terminal Equipment (TE) of the QoS of the downlink data packet. Alterna- 
tively the MS might use some GPRS or PPP specific mechanisms for deliver- 
ing the same information to the TE. Scheduling and policing operations inside 
35 the network elements are basically the same in both directions. 
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As noted above, for uplink data, the GGSN, or an external host, 
modifies the GPRS QoS information to the QoS concepts available in the ex- 
ternal packet data network. Similarly, for downlink data, the GGSN, or an ex- 
ternal host, should translate the external network QoS into the GPRS QoS 

5 definitions in each data packet. The GGSN, or an external host, may optionally 
maintain information about different application connections and traffic flows, 
but this is not required. The flow information can be obtained for example via 
RSVP signalling taking place in the network. The GGSN, or an external host, 
may response to external RSVP messages itself, or it may also pass the 

10 RSVP messages to the MS which may take part in the RSVP signalling. The 
capacity indicated in RSVP response messages should be in line with the ca- 
pacity reserved for the corresponding QoS profile in the GPRS network. 

As described in the examples above, the Differentiated Services in 
the Internet, like the SIMA approach, can be mapped quite easily to these new 

15 GPRS QoS concepts. For Differentiated Services, a separate QoS profile 
could be established for each traffic type (i.e. attribute combinations, per-hop 
behaviours) requiring a particular service from the network. The Integrated 
Services are usually associated with traffic flows, which can be mapped to 
different QoS profiles within the GPRS. The Guaranteed Service can thus be 

20 defined as with the RSVP: the GGSN, or an external host, and the MS on the 
other side, may provide the mapping between QoS profiles and external traffic 
flows, as well as the mapping of QoS parameters. During the RSVP negotia- 
tion, the GPRS system may indicate that it cannot support various token 
bucket sizes or maximum packet sizes. Thus, it may require that those pa- 

25 rameters are set to conform to the supported values before it will accept the 
RSVP reservations. The MS, the SGSN, the GGSN or an external host may 
also know the free capacity in the network and make a decision on the ac- 
ceptance of each reservation request based on this information. 

Also ATM (Asynchronous Transfer Mode) or X.25 can be used as 

30 an external data network or as a transmission medium to convey the GPRS 
signalling and data traffic. The ATM Constant Bit Rate (CBR) and real-time 
Variable Bit Rate (r-VBR) traffic may be mapped to real-time traffic class and 
the other ATM traffic classes to non-real-time traffic. Priority may be decided 
based on both the used traffic class (non-real-time Variable Bit Rate, Alterna- 
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tive Bit Rate, or Unspecified Bit Rate) and other connection-related parame- 
ters, such as mean and maximum bit rate. 

IP networks will be used as an underlying transmission network in 
the GPRS backbone. The GPRS QoS concepts may be mapped to the Type- 

5 Of-Service parameter in the IPv4, or to the Priority/Traffic Class field in the 
IPv6, and vice versa. The flows in the IPv6 can also be used to reserve a cer- 
tain kind of capacity and to handle certain traffic types, application connec- 
tions, or PDP contexts. If the external Internet network also employs these 
methods, the GGSN, or an external host, could perform mapping of concepts 

10 similarly between the GPRS network and the Internet. 

Similarly as described above with respect to the GPRS, the present 
invention is applicable in any mobile communications network. Potential mo- 
bile networks in which the principles of the present invention may be applied 
are the third generation mobile communications systems, such as the Univer- 

15 sal Mobile Communications System (UMTS) and the Future Public Mobile 
Telecommunication System (FPLMTS), or lMT-2000, or the Cellular Digital 
Packet Data (CDPD). 

The description only illustrates preferred embodiments of the inven- 
tion. The invention is not, however, limited to these examples, but it may vary 

20 within the scope of the appended claims. 
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Claims 

1. A method for transmitting data packets (DP) in multiple data flows 
to/from a mobile station (MS) in a mobile communications system (HPLMN, 
VPLMN) having a packet data transmission capability, the method comprising 
5 the steps of: 

setting up a data transmission path for the mobile station (MS) for 
routing data packets (DP) through the mobile communications system 

(HPLMN, VPLMN); 

transmitting data packets (DP) through the mobile communications 
10 system (HPLMN) between said mobile station (MS) and an external communi- 
cation system (11,12. VPLMN, HPLMN); 

associating at least one profile (Pr) with said data transmission 
path, said at least one profile comprising at least one quality of service pa- 
rameter, or QoS parameter; 
15 scheduling and policing the transmission of the data packets (DP) 

within at least one QoS parameter indicated by said profile (Pr); 
characterized by the further steps of. 

associating multiple profiles (Pr) with the transmission path, each 
profile (Pr) comprising at least one QoS parameter; 
20 providing each one of said multiple flows with a profile tag (PrT) in- 

dicating one of the multiple profiles (Pr) associated with the transmission path 
in question; and 

scheduling and policing the transmission of individual data packets 
(DP) on the basis of said at least one QoS parameter of the profile (Pr) indi- 
25 cated by the profile tag (PrT) associated with the data flow in question. 

2. A method according to claim ^characterized by the steps 

of 

executing at least two applications in said mobile station (MS), each 
application belonging to a class/type and having and at least one flow associ- 

30 ated thereto; 

transmitting, within a single transmission path, data packets (DP) of 

said at least two applications; and 

providing each flow of each application class/type with a profile tag 
(PrT) indicating the QoS parameter required by the respective application 
35 class/type. 
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3. A method according to claim 2, characterized by providing 
each flow of each individual application with a profile tag (PrT). 

4. A method according to any one of the preceding claims, char- 
acterized by providing substantially each individual data packet (DP) with 

5 a profile tag (PrT). 

5. A method according to any one of the preceding claims, char- 
acterized by providing, as QoS parameters, each profile (Pr) with priority 
information indicating one of at least two priority levels. 

6. A method to any one of the preceding claims, character- 
ized by the steps of 

providing in the mobile communications system at least one con- 
nection leg with at least two paths having different reliabilities; 

providing, as one QoS parameter, each profile (Pr) with reliability 
information indicating one of at least two reliability classes; and 

multiplexing the data packets (DP) to said at least two paths ac- 
cording to said reliability information. 

7. A method to any one of the preceding claims, character- 
ized by the steps of 

forming in the mobile communications system at least one connec- 
tion leg wrth a connection-oriented path and a connectionless path, the former 
being more reliable than the latter; 

deciding whether to send a data packet (DP) over the connection- 
oriented path or the connectionless path on the basis of said reliability infor- 
mation. 

8. A method to claim 7, characterized by multiplexing data 
packets (DP) associated with two or more profiles (Pr) to said connection- 
oriented and connectionless paths in said at least one connection leg. 

9. A method to any one of the preceding claims, character- 
ized in that at least one of the profiles (Pr) comprises at least one further 
QoS parameter indicating a further limit for said scheduling and policing. 
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10. A method as claimed in claim 9, characterized in that 
said at least one further QoS parameter includes one or more of the following: 
mean bit rate, peak bit rate, service precedence, delay class and reliability. 

1 1 . A method to any one of the preceding claims, character- 

5 i z e d in that 

said at least one further QoS parameter defines a mean bit rate; 
the actual mean bit rate used by the mobile station (MS) is moni- 
tored: and 

data packets (DP) to/from the mobile station (MS) are discarded, or 
10 at least their precedence is lowered, if the actual mean bit rate exceeds the 
mean bit rate defined by said at least one further QoS parameter. 

12. A method to any one of the preceding claims, character- 
ized by mapping QoS parameters used in the mobile communications sys- 
tem (HPLMN, VPLMN) to those used in a user application in said mobile sta- 

15 tion (MS) or those used in said external communication system (11, 12, 
VPLMN), and vice versa. 

1 3. A method to any one of the claims 2 to 12, characterized 

by: 

establishing one default profile (Pr 0 ) which is associated with said 
20 transmission path, and a specific profile (Pr) for each application or application 
class/type being executed in the mobile station; and 

reading a QoS parameter from the default profile (Pr 0 ) if the corre- 
sponding QoS parameter is missing from the specific profile in question. 

14. A method according to any one of the preceding claims, 
25 characterized by associating a packet data protocol context known per 

se with the transmission path. 

15. A method according to claim 13, c h a r a ct e r i z e d by asso- 
ciating said multiple profiles (Pr) with said packet data protocol context. 

16. An apparatus (MS, GGSN) for transmitting data packets (DP) in 
30 multiple data flows in a mobile communications system (HPLMN, VPLMN) 

having a packet data transmission capability, the apparatus being arranged to: 
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set up a data transmission path for the mobile station (MS) for rout- 
ing data packets (DP) through the mobile communications system (HPLMN, 
VPLMN); 

transmit data packets (DP) through the mobile communications 
5 system (HPLMN) between said mobile station (MS) and an external communi- 
cation system (1 1 , 12, VPLMN, HPLMN); 

associate at least one profile (Pr) with said data transmission path, 
said at least one profile comprising at least one quality of service parameter, 
or QoS parameter; 

10 schedule and police the transmission of the data packets (DP) 

within at least one QoS parameter indicated by said profile (Pr); 

characterized in that the apparatus is arranged to: 
associate multiple profiles (Pr) with the transmission path, each 
profile (Pr) comprising at least one QoS parameter; 
1 5 provide each one of said multiple flows with a profile tag (PrT) indi- 

cating one of the multiple profiles (Pr) associated with the transmission path in 
question; and 

schedule and police the transmission of individual data packets 
(DP) on the basis of said at least one QoS parameter of the profile (Pr) indi- 
20 cated by the profile tag (PrT) associated with the data flow in question. 

17. An apparatus according to claim 16, characterized in 
that the apparatus is or comprises a mobile radio station (MS). 



18. An apparatus according to claim 16, characterized in 
that the apparatus is a support node (SGSN, GGSN) of a packet radio network 
25 (HPLMN, VPLMN). 
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(57) Abstract 

A method for transmitting data packets (DP) in multiple 
data flows to/from a mobile station (MS) in a mobile 
communications system (HPLMN, VPLMN). A data 
transmission path is formed for routing data packets 
(DP). Multiple profiles (Pr) are associated with the data 
transmission path, each profile (Pr) comprising at least 
one quality of service parameter, or QoS parameter. 
Each flow or data packet (DP) is provided with a profile 
tag (PrT) indicating one of the multiple profiles (Pr). 
Scheduling and policing the transmission of individual 
data packets (DP) is based on at least one QoS pa- 
rameter of the profile (Pr) indicated by the profile tag 
(PrT) associated with the data flow in question. 



(Fig- 1) 
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